I understand that the current implementation rejects this input immediately because it contains duplicate placeholders, but I think this 100_000 length case is still worth preserving as a regression test. I might retain it as a simple standalone test that preserves the long string input (and probably only needs to be checked against one pattern, not all). I say this because I don't think the test should be relying on an assumption of the current implementation.

ListFormat uses MessageFormat, which means that any patterns taken by the former get passed to the latter.

What would we expect to happen if {3} was passed as a pattern. Do we expect that to be printed out literally? Do we expect to reject it because it takes the form of a placeholder but exceeds the 0-2 value range?

In the current form, depending on the number of elements, it could either be printed out literally, or it could be interpreted as a MessageFormat pattern. For example,

String[] p = {
      "{3} {0}, {1}",
      "{0}, {1}",
      "{0}, and {1}",
      "",
      "" 
};
var lf = ListFormat.getInstance(p);
lf.format(List.of("a", "b", "c", "d")); // -> d a, b, c, and d
lf.format(List.of("a", "b", "c")); // -> {3} a, b, and c

I would not be opposed to rejecting any placeholders that are not in the form of only 0, 1, and 2. I am going to guess that no locales rely on {HARD_CODED_NUMBER} as being a part of their list patterns. What do you think?

Good point. I think rejecting is fine. In fact, I made it stricter as any curly brace use other than 0/1/2 now throws an exception because MessageFormat has its own parsing, which prevents "{foo}" from working as a literal.

I think "The string array passed to the method" reads better.

Recommend: If the {@code two} ...

We won't have support for literal braces which seems reasonable for these list patterns. There could always be an escaping mechanism for such support, but seems unnecessary for now unless there was a genuine request/demand.

Since validatePlaceholders already iterates through the entire pattern string to validate braces, I think we can just merge the logic of findPlaceholders and validatePlaceholders into this main loop to do validation and placeholder recording.

Instead of

        var positions = new int[3];
        for (int i = 0; i < positions.length; i++) {
            var ph = "{" + i + "}";
            positions[i] = pattern.indexOf(ph);
            if (positions[i] >= 0) {
                // Check for duplicate placeholders
                if (pattern.indexOf(ph, positions[i] + PLACEHOLDER_LENGTH) >= 0) {
                    return null;
                }
            }
        }

I think we can just initialize positions as new int[] {-1, -1, -1}; and if positions[index] != -1 we can fail. We can derive the correct index via pattern.charAt(i + 1) - '0' (given this code occurs within the ch == '{' block).

Yes. That'd be simpler/performant. Fixed.